The present invention relates generally to managing resources that are accessible to a plurality of entities and, more specifically, to distributing the job of mastery of a resource by one primary resource master to one or more secondary resource masters.
Database servers use resources while executing transactions. Even though resources may be shared between database servers, many resources may not be accessed in certain ways by more than one process at any given time. For example, resources such as data blocks of a storage medium or tables stored on a storage medium may be concurrently accessed in some ways (e.g. read) by multiple processes, but accessed in other ways (e.g. written to) by only one process at a time. Consequently, mechanisms have been developed which control access to resources.
One such mechanism is referred to as a lock. A lock is a data structure that indicates that a particular process has been granted certain rights with respect to a resource. There are many types of locks. Some types of locks may be shared on the same resource by many processes, while other types of locks prevent any other locks from being granted on the same resource.
The entity responsible for granting locks on resources is referred to as a lock manager. In a single node database system, a lock manager will typically consist of one or more processes on the node. In a multiple-node system, such as a multi-processing machine or a local area network, a lock manager may include processes distributed over numerous nodes. A lock manager that includes components that reside on two or more nodes is referred to as a distributed lock manager.
FIG. 1 is a block diagram of a multiple-node computer system 100. Each node is executing an instance of a database server and a portion of a distributed lock management system 132. Specifically, the illustrated system includes three nodes 102, 112 and 122 on which reside database servers 104, 114 and 124, respectively, and lock manager units 106, 116 and 126, respectively. Database servers 104, 114 and 124 have access to the same database 120. The database 120 resides on a disk 118 that contains multiple blocks of data. Disk 118 generally represents one or more persistent storage devices that may be on any number of machines, including but not limited to the machines that contain nodes 102, 112 and 122.
A communication mechanism allows processes on nodes 102, 112, and 122 to communicate with each other and with the disks that contain portions of database 120. The specific communication mechanism between the nodes and disk 118 will vary based on the nature of system 100. For example, if the nodes 102, 112 and 122 correspond to workstations on a network, the communication mechanism will be different than if the nodes 102, 112 and 122 correspond to clusters of processors and memory within a multi-processing machine.
Before any of database servers 104, 114 and 124 can access a resource shared with the other database servers, it must obtain the appropriate lock on the resource from the distributed lock management system 132. Such a resource may be, for example, one or more blocks of disk 118 on which data from database 120 is stored.
Lock management system 132 stores data structures that indicate the locks held by database servers 104, 114 and 124 on the resources shared by the database servers. If one database server requests a lock on a resource while another database server has a lock on the resource, the distributed lock management system 132 must determine whether the requested lock is consistent with the granted lock. If the requested lock is not consistent with the granted lock, then the requester must wait until the database server holding the granted lock releases the granted lock.
According to one approach, lock management system 132 maintains one master resource object for every resource managed by lock management system 132, and includes one lock manager unit for each node that contains a database server. The master resource object for a particular resource stores, among other things, an indication of all locks that have been granted on or requested for the particular resource. The master resource object for each resource resides within only one of the lock manager units 106, 116 and 126.
The node on which a lock manager unit resides is referred to as the xe2x80x9cmaster nodexe2x80x9d (or simply xe2x80x9cmasterxe2x80x9d) of the resources whose master resource objects are managed by that lock manager unit. Thus, if the master resource object for a resource R1 is managed by lock manager unit 106, then node 102 is the master of resource R1.
In conventional distributed lock manager systems, all requests for a resource go through the resource master of that resource. When the master of a resource exits normally or abnormally, the distributed lock manager system 132 has to select one or more of the remaining nodes to become the masters for the resources that were mastered by the terminated node. The process of rebuilding the master resource object at a new master node may involve collecting lock information for every remaining node in the distributed lock manager system 132. Consequently, the task of rebuilding the master resource objects that resided on a failed node may be time consuming. Further, the amount of time required for the task increases as the number of nodes and/or the number of resources increases.
Unfortunately, during the process of rebuilding master resource objects on other nodes, all lock operations are suspended on the resources that are being remastered. Thus, when a node fails, the resources that were mastered by that node may become unavailable for an extended period of time. The extended unavailability of those resources may be unacceptable.
Based on the foregoing, it is clearly desirable to provide techniques for improving resource management. In particular, it is desirable to provide techniques that increase the availability of resources while the resources are being remastered.
Techniques are disclosed for managing access to a set of one or more resources that are accessible to a plurality of entities. In one embodiment, one primary resource master and one or more secondary resource masters are established for a given resource. Each resource master (whether primary or secondary) is assigned to be the master for the resource for a corresponding subgroup of entities of the plurality of entities. Each secondary resource master is assigned to a parent resource master, which may either be the primary resource master or another secondary resource master.
Each entity of the plurality of entities, upon seeking access to the resource, requests a lock on the resource from the resource master that is assigned to the subgroup that includes that entity. A secondary resource master communicates with its parent resource master for information regarding locks on a resource when the information maintained by that secondary resource master is insufficient for that secondary resource master to determine whether a particular lock on the resource can be granted.
When the primary resource master fails, the secondary resource masters may continue to manage and grant locks for the resource as long as the granting of the locks does not require information that was only on the primary resource master.
A resource master may be assigned to a subgroup of entities based on various factors, such as system configurations, similarity of tasks performed by each entity in the subgroup of entities, similarity of performance speed of each entity in the subgroup of entities, similarity of distances from each entity to the resource master to which the subgroup that includes the entities is assigned, etc.